Interface programs that enable communications between application programs and network functionality have previously been constructed in such a way that information regarding network communication protocols and the format for particular transport mechanisms was fed to the interface program by the application. In such cases, each application program has to maintain an updated knowledge of the set of network protocols and transport mechanisms in order to provide the correct information to the interface program. In other words, a software application program may have to understand the topology of the hardware and software components in order to function correctly. Moreover, each application program may have to be modified to take advantage of new delivery mechanisms and technologies.
A common issue to component based solutions is that, as an application program is scaled in size, software components may have to be moved to other processes and potentially additional machines to provide for increased capacity. Here too, the application programs on a given system may have to be reworked as the relationship between components change. Modifying the proliferating number of application programs on a system to keep up with these changes is labor-intensive and error-prone. Entire programs may have to be analyzed with each change since a bug in a single portion of a given program may bring the entire system/network down.
Further, the interoperation between dissimilar messaging systems and their transport mechanisms may be difficult to accomplish. For example, common object request broker architecture (CORBA), remote procedure call (RPC), socket, Java messaging service (JMS), and Tuxedo are all examples of different transport mechanisms for passing information between software components. These transport mechanisms may not interoperate with each other and often even struggle to interoperate between like message types. It is not uncommon for CORBA implementation to not interoperate with other transport mechanisms. JMS implementations will not interoperate if not provided by the same vendor. This is because JMS defined an application program interface (API) but did not specify the protocol. Sockets provide intercommunication but the applications using the sockets must come to agreement of the message structures, e.g., message format, that will be used over the interface and very often cause the messaging to be tied to a specific hardware architecture.
Consider the case of a network which employs the TCP/IP protocol. This type of network may require that the interface establish a “socket”. A socket is a software construct which defines a repository or queue in a computer's operating system for data being transmitted/received, keeps track of various parameters of a communication session, the necessary protocol and command information for the session, etc. In some approaches, an application program requests the creation of a “socket” from a network library. The network library would then provide the communication functionality for various application programs. However, the application program is responsible for informing the network library of the protocol that is to be utilized over the particular network. Further, the application program informs the network library of the address format and various other details of how the addresses are to be administered by the protocol.
A principal difficulty with the above-indicated procedure is that the application program needs to maintain updated records of the most current protocols to enable communications to be successfully accomplished. Thus, each time a protocol is added, each application needs to be revised in order to reflect the most updated version.
The socket creation procedure works well with monolithic applications which employ non-extensible network libraries. That is, some piece of code in some part of an application will always know which protocol is being used or is to be used. In a monolithic application, all developed by a single team, it is reasonable to let such knowledge infiltrate other parts of the application. However, today it is common for different teams to work on different components that make up a software product, and for those components to be used in many applications.
These issues are compounded in systems which convert computer network messages into messages that can be delivered to a wireless device, e.g., a pager, a cellular telephone, a personal communications services (PCS) device, etc. Wireless transport mechanisms include modems, the Internet, ITU standards, TTY (teletype), and TCP transport architectures. Each of these wireless transport mechanisms may support multiple communication protocols. For example, a wireless transport mechanism may have to support the TAP (telocator alphanumeric protocol) for one way alphanumeric paging, the Touch Tone protocol for tone numeric paging, the SOAP (simple object access protocol), various proprietary two-way SMS (short message service) protocols for digital cellular telephones, etc.